系統發展生命周期（System Development Life Cycle，SDLC），參考wiki：
https://zh.wikipedia.org/zh-tw/%E7%B3%BB%E7%BB%9F%E5%8F%91%E5%B1%95%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F

隨著時間前進，有各種開發模式理論被一直提出來，而喜新厭舊（X）怕趕不上流行（O）的廣大工程師們，就被一直推著往前走。

用「SDLC models」問google，可以得到好幾個有關的內容，每個網站都有廣告Orz，所以我就選這一個來源資料吧：
https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm

而如果想快速了解各種方式的優劣，可以用「sdlc model recommend」問google，我覺得這篇寫得還不錯：有圖解一看就懂。
https://www.rnftechnologies.com/blog/best-sdlc-methodology

這次開發，主要因為單人作業，一條龍就傳統瀑布式最單純：

圖片來源： https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

主要階段為

1. 需求分析（Requirement Analysis）
2. 系統設計（System Design）
3. 實作（Implementation）
4. 測試（Testing）
5. 佈署（Deployment）
6. 維護（Maintenance）

在我待過的工作裡，通常第一階段，我通常把他算成 RA + SA（system analysis） 。參考wiki：https://en.wikipedia.org/wiki/Systems_analysis。
SA 除了是一個階段之外，通常也是公司的一個職位名稱，而當職位名稱時，要記得這只是個職稱，並不代表他的工作職責範圍！不要先入為主就沒有期待，沒有傷害。而SD也是同樣的情況。

在實務上，開發方式，我覺得選那個都好，因為都有其優缺點，與當下適合的時空背景，評估過後定好了就好。而開發方式需要團隊一起遵守實行才會有效，我待的同溫層，基本上還是看主管/Leader想怎麼做為主。而公司政策講一套，實際運作是另一套的也不少，或是只是開個立會就自以為敏捷的這種奇妙觀念也有...

反正真正的專案軟體開發在進行的時後，都是什麼意外都不意外…要怎麼解決意外都是要看當事者的智慧，協調能力跟配合度。理想上想當個以人為本，人人有人權尊嚴的工作並不是那麼容易，畢竟無法身處傳說中的頂尖企業，不能期望同事IQ PR90 + EQ PR90 還要充滿工作熱誠，自己都作不到的事，就不要苛求別人太多，不順的時候就只能靠包容跟風險容錯空間/Buffer來用。

總之個人小小的願望就是，只要最後不要變成隕石就好！